Hadoop版本
Hadoop版本种类
目前Hadoop发行版非常多,有华为发行版、Intel发行版、Cloudera发行版(CDH)等,所有这些发行版均是基于Apache Hadoop衍生出来的,之所以有这么多的版本,完全是由Apache Hadoop的开源协议决定的:任何人可以对其进行修改,并作为开源或商业产品发布/销售。
国内绝大多数公司发行版是收费的,比如Intel发行版、华为发行版等,尽管这些发行版增加了很多开源版本没有的新feature,但绝大多数公司选择Hadoop版本时会将把是否收费作为重要指标,不收费的Hadoop版本主要有三个(均是国外厂商),分别是:Cloudera版本(Cloudera’s Distribution Including Apache Hadoop,简称“CDH”)、Apache基金会hadoop、Hortonworks版本(Hortonworks Data Platform,简称“HDP”)。按顺序代表了,在国内的使用率,CDH和HDP虽然是收费版本,但是他们是开源的,只是收取服务费用。
Apache社区版本:
完全开源,免费,非商业。apache社区的hadoop版本分枝较多,而且部分hadoop存在bug。在选择hadoop,hbase,hive等时,需要考虑兼容性。
Cloudera版本:
开源,免费,有商业和非商业版本。是在apache社区版本的hadoop基础上,选择相对稳定版本的hadoop,并在此基础上,进行bug修改和维护。使用者不必考虑hadoop,hbase,hive等在使用过程中,版本兼容性。
Hortonworks版本:
开源,免费,有商业和非商业版本。是在Apache基础上修改,具有apache的特色。
Apache Hadoop版本衍化
Apache Hadoop版本分为两代,我们将第一代Hadoop称为Hadoop 1.0,第二代Hadoop称为Hadoop 2.0。第一代Hadoop包含三个大版本,分别是0.20.x,0.21.x和0.22.x,其中,0.20.x最后演化成1.0.x,变成了稳定版,而0.21.x和0.22.x则NameNode HA等新的重大特性。第二代Hadoop包含两个版本,分别是0.23.x和2.x,它们完全不同于Hadoop 1.0,是一套全新的架构,均包含HDFS Federation和YARN两个系统,相比于0.23.x,2.x增加了NameNode HA和Wire-compatibility两个重大特性。经过上面的大体解释,大家可能明白了Hadoop以重大特性区分各个版本的,总结起来,用于区分Hadoop版本的特性有以下几个:
- Append 支持文件追加功能,如果想使用HBase,需要这个特性。
- RAID 在保证数据可靠的前提下,通过引入校验码较少数据块数目.
- Symlink支持HDFS文件链接
- Security Hadoop安全。
需要注意的是,Hadoop 2.0主要由Yahoo独立出来的hortonworks公司主持开发。
2013年10月,Hadoop 2.0发布。关键特性包括:
- YARN
YARN是“Yet Another Resource Negotiator”的简称,它是Hadoop 2.0引入的一个全新的通用资源管理系统,可在其之上运行各种应用程序和框架,比如MapReduce、Tez、Storm等,它的引入使得各种应用运行在一个集群中成为可能。YARN是在MRv1基础上衍化而来的,是MapReduce发展到一定程度的必然产物,它的出现使得Hadoop计算类应用进入平台化时代,博客中包含大量介绍YARN的文章,有兴趣的读者可阅读:http://dongxicheng.org/category/mapreduce-nextgen/ - HDFS单点故障得以解决
Hadoop 2.2.0同时解决了NameNode单点故障问题和内存受限问题,其中,单点故障是通过主备NameNode切换实现的,这是一种古老的解决服务单点故障的方案,主备NameNode之间通过一个共享存储同步元数据信息,因此共享存储系统的选择称为关键,而Hadoop则提供了NFS、QJM和Bookeeper三种可选的共享存储系统,具体可阅读我的这篇文章:Hadoop 2.0单点故障问题方案总结。 - HDFS Federation
前面提到HDFS 的NameNode存在内存受限问题,该问题也在2.2.0版本中得到了解决。这是通过HDFS Federation实现的,它允许一个HDFS集群中存在多个NameNode,每个NameNode分管一部分目录,而不同NameNode之间彼此独立,共享所有DataNode的存储资源,注意,NameNode Federation中的每个NameNode仍存在单点问题,需为每个NameNode提供一个backup以解决单点故障问题。 - HDFS快照
HDFS快照是指HDFS文件系统(或者子系统)在某一时刻的只读镜像,它的出现使得管理员可定时为重要文件或目录做快照,以防止数据误删、丢失等。具体可阅读:Snapshots for HDFS(使用说明),Support for RW/RO snapshots in HDFS。
通过NFSv3访问HDFS
NFS允许用户像访问本地文件系统一样访问远程文件系统,而将NFS引入HDFS后,用户可像读写本地文件一样读写HDFS上的文件,大大简化了HDFS使用,这是通过引入一个NFS gateway服务实现的,该服务能将NFS协议转换为HDFS访问协议,具体如下图所示。有兴趣的读者可阅读:Support NFSv3 interface to HDFS,以及相关设计文档:HDFS NFS Gateway。 - 支持Windows操作系统
在2.2.0版本之前,Hadoop仅支持Linux操作系统,而Windows仅作为实验平台使用。从2.2.0开始,Hadoop开始支持Windows操作系统,具体可阅读我之前写的一篇文章:Hadoop For Windows。 - 兼容1.x上运行的MapReduce应用程序与Hadoop生态系统其他系统进行了充分的集成测试
除了HDFS、MapReduce和YARN这三个核心系统外,Hadoop生态系统还包括Hbase、Hive、Pig等系统,这些系统底层依赖于Hadoop内核,而相比于Hadoop 1.0,Hadoop 2.0的最大变化出现在内核(HDFS、MapReduce和YARN),但与生态系统中其他系统进行集成测试是必需的。
除了以上特性外,Apache官方还给出了两个特殊说明:
- HDFS变化:HDFS的symlinks(类似于Linux中的软连接)被将移到了2.3.0版本中
- YARN/MapReduce注意事项:管理员在NodeManager上设置ShuffleHandler service时,要采用“mapreduce_shuffle”,而非之前的“mapreduce.shuffle”作为属性值。
新版本不仅增强了核心平台的大量功能,同时还修复了大量bug。新版本对HDFS做了两个非常重要的增强:
- 支持异构的存储层次;
- 通过数据节点为存储在HDFS中的数据提供了内存缓存功能。
借助于HDFS对异构存储层次的支持,我们将能够在同一个Hadoop集群上使用不同的存储类型。此外我们还可以使用不同的存储媒介——例如商业磁盘、企业级磁盘、SSD或者内存等——更好地权衡成本和收益。如果你想更详细地了解与该增强相关的信息,那么可以访问这里。类似地,在新版本中我们还能使用Hadoop集群中的可用内存集中地缓存并管理数据节点内存中的数据集。MapReduce、Hive、Pig等类似的应用程序将能够申请内存进行缓存,然后直接从数据节点的地址空间中读取内容,通过完全避免磁盘操作极大地提高扫描效率。Hive现在正在为ORC文件实现一个非常有效的零复制读取路径,该功能就使用了这项新技术。
在YARN方面,令我们非常兴奋的事情是资源管理器自动故障转移功能已经进入尾声,虽然在2.3.0这个版本中该功能还没有被发布,但是极有可能会包含在Hadoop-2.4中。此外,2.3.0版本还对YARN做了一些关键的运维方面的增强,例如更好的日志、错误处理和诊断等。
MapReduce的一个关键增强MAPREDUCE-4421。借助于该功能我们已经不再需要在每一台机器上安装MapReduce二进制程序,仅仅需要通过YARN分布式缓存将一个MapReduce包复制到HDFS中就可以了。当然,新版本还包含大量的bug修复以及其他方面的增强。例如:
- YarnClientImpl类中的异步轮询操作引入了超时;
- 修复了RMFatalEventDispatcher没有记录事件原因的问题;
- HA配置不会影响节点管理器的RPC地址;
- RM Web UI和REST API统一使用YarnApplicationState;
- 在RpcResponseHeader中包含RPC错误信息,而不是将其分开发送;
- 向jetty/httpserver中添加了请求日志;
- 修复了将dfs.checksum.type定义为NULL之后写文件和hflush会抛出java.lang.ArrayIndexOutOfBoundsException的问题。
2014年4月,Hadoop 2.4.0发布。关键特性包括:
- HDFS支持访问控制列表(ACLs,Access Control Lists);
- 原生支持HDFS滚动升级;
- HDFS FSImage用到了 protocol-buffers,从而可以平滑地升级;
- HDFS完全支持HTTPS;
- YARN ResourceManager支持自动故障转移,解决了YARN ResourceManager的单点故障;
- 对YARN的Application History Server和 pplication Timeline Server上的新应用加强了支持;
- 通过抢占使得YARN Capacity Scheduler支持强SLAs协议;
安全对于Hadoop来说至关重要,所以在Hadoop 2.4.0版本中对HDFS的所有访问(包括WebHDFS, HsFTP甚至是web-interfaces)都支持了HTTPS。在Hadoop 2.4.0解决了ResourceManager的单点故障。这样会在集群中存在两个ResourceManager,其中一个处于Active;另一个处于 standby。当Active的出现故障,这样Hadoop可以自动平滑地切换到另外一个ResourceManager,这个新的ResourceManager将会自动的重启那些提交的applications。在下一阶段,Hadoop将会增加一个热standby(add a hot standby),这个standby可以继续从故障点运行的应用程序,以保存任何已经完成的工作。
2014年8月,Hadoop 2.5.0发布。关键特性包括:
- Common
- 使用HTTP代理服务器时认证改进。当通过代理服务器使用WebHDFS时这是非常有用的。
- 增加了一个新的Hadoop指标监控sink,允许直接写到Graphite。
- Hadoop文件系统兼容相关的规范工作。
- HDFS
- 支持 POSIX风格的扩展文件系统。更多细节查看Extended Attributes in HDFS文档。
- 支持离线image浏览,客户端现在可以通过WebHDFS的API浏览一个fsimage。
- NFS网关得到大量可支持性的改进和bug修复。Hadoop portmapper不在需要运行网关,网关现在可以拒绝没有权限的端口的连接。
- SecondaryNameNode, JournalNode, and DataNode 的web UI已经使用HTML5和JS美化。
- YARN
- YARN的REST API现在支持写/修改操作。用户可以用REST API提交和杀死应用程序。
- 时间线存储到YARN,用来存储一个应用通用的和特殊的信息,支持Kerberos认证。
- 公平调度器支持动态分层用户队列,运行时,用户队列在任一指定的父队列中被动态的创建。
2014年11月,Hadoop 2.6.0发布。关键特性包括:
- Common
Hadoop Key Management Server(KMS)是一个基于HadoopKeyProvider API编写的密钥管理服务器。他提供了一个client和一个server组件,client和server之间基于HTTP协议使用REST API通信。Client是一个KeyProvider的实现,使用KMS HTTP REST API与KMS交互。KMS和它的client有内置的安全机制,支持HTTP SPNEGO Kerberos认证和HTTPS安全传输。KMS是一个Java Web应用程序,运行在与Hadoop发行版绑定在一起的预先配置好的Tomcat服务器上。 - Tracing
HDFS-5274增加了追踪通过HDFS的请求的功能,此功能使用了开源的库,HTrace。大家可以看一下HTrace,功能很强大,Cloudera开源出来的。 - HDFS
- Transparent Encryption,HDFS实现了一个透明的,端到端的加密方式。一旦配置了加密,从HDFS读出数据解密和写入数据加密的过程对用户应用程序代码带来说都是透明的。加密过程是端到端的,这意味着数据只能在客户端被加密解密。HDFS从来不存储,也不访问未加密的数据和数据加密密钥。这样满足了加密过程的两个典型的需求:at-rest encryption(静态加密,也就是说,数据持久化在像硬盘这样的媒介上),in-transit encryption(在途加密,例如,当数据在网络中传输的时候)。
- Storage SSD && Memory。ArchivalStorage(档案存储器)是将计算能力与不断增长的存储能力分离。拥有高密度低成本的存储但是计算能力较低的节点将变得可用,可以在集群中做冷存储。增加更多的节点作为冷存储可以提高集群的存储能力,跟集群的计算能力无关。
- MapReduce
这一部分主要是一些bug的修复和改进。增加了两个新的新特,在2.5.2里已经有所描述了。这里在简单看一下。- ResourceManger Restart
- 允许AM发送历史事件信息到timeline server。
- YARN
- NodeManager Restart:这个特性可以使NodeManager在不丢失运行在节点中的活动的container的情况下重新启动。
- Docker Container Executor:DockerContainer Executor(DCE)允许YARN NodeManager在Docker container中启动YARN container。用户可以指定他们想用来运行YARN container的Docker的镜像。这些container提供了一个可以自定义的软件环境,用户的代码可以运行在其中,与NodeManager运行的环境隔离。这些运行用户代码的container可以包含应用程序需要的特定的库,它们可以拥有与NodeManager不同版本的Perl,Python甚至是Java。事实上,这些container可以运行与NodeManager所在的OS不同版本的Linux。尽管YARN container必须定义运行Job所需的所有的环境和库,但是NodeManager中的所有的东西都不会共享。
Docer为YARN提供了一致和隔离两种模式,一致模式下,所有的YARN container将拥有相同的软件环境,在隔离模式下,不管物理机器安装了什么都不干扰。
2015年7月,Hadoop 2.7.0发布。关键特性包括:
- Common
支持Windows Azure Storage,BLOB作为Hadoop中的文件系统。
Hadoop HDFS- 支持文件截断(file truncate);
- 支持每个存储类型配额(Support for quotas per storage type);
- 支持可变长度的块文件
- YARN —— YARN安全模块可插拔
- YARN的本地化资源可以自动共享,全局缓存(测试版)
Hadoop MapReduce - 能够限制运行的Map/Reduce作业的任务
- 为非常的大Job(有许多输出文件)加快了FileOutputCommitter。
- YARN的本地化资源可以自动共享,全局缓存(测试版)
- HDFS
- 支持文件截断(file truncate);
- 支持每个存储类型配额(Support for quotas per storage type);
- 支持可变长度的块文件
- MAPREDUCE
- 能够限制运行的Map/Reduce作业的任务
- 为非常的大Job(有许多输出文件)加快了FileOutputCommitter。
2015年7月,Hadoop 2.7.1发布。关键特性包括:
本版本属于稳定版本,是自Hadoop 2.6.0以来又一个稳定版,同时也是Hadoop 2.7.x版本线的第一个稳定版本,也是 2.7版本线的维护版本,变化不大,主要是修复了一些比较严重的Bug(其中修复了131个Bugs和patches)
安装部署Hadoop
Hadoop 有两个主要版本,Hadoop 1.x.y 和 Hadoop 2.x.y 系列,比较老的教材上用的可能是 0.20 这样的版本。Hadoop 2.x 版本在不断更新。
Hadoop安装部署模式有3种:
- Local (Standalone) Mode 本地模式
- Pseudo-Distributed Mode 伪分布式模式
- Fully-Distributed Mode 完全分布式模式(即为多节点安装Hadoop)
安装部署本地模式Hadoop
本次实验使用的版本是hadoop-2.7.2,实验环境如下:
主机名 | IP地址 | 操作系统版本 | 安装软件 |
---|---|---|---|
node3 | 172.16.7.153 | CentOS 7.1 | hadoop-2.7.2 |
安装JDK1.7
Hadoop Java Versions
Version 2.7 and later of Apache Hadoop requires Java 7. It is built and tested on both OpenJDK and Oracle (HotSpot)’s JDK/JRE.
Earlier versions (2.6 and earlier) support Java 6.
安装依赖包ssh和rsync
对于Redhat/CentOS系列的,安装系统时一般都会默认安装openssh软件,里面包含了ssh客户端和ssh服务端,所以先检查下这个软件包是否安装了:
如果没有安装,安装:
在检查rsync软件包是否安装:
添加Hadoop运行用户
|
|
配置主节点登录自己和其他节点不需要输入密码
使用hadoop用户登录主机,配置其ssh连接localhost不需要输入密码:
此时再用 ssh localhost,无需输入密码就可以直接登陆了,如下图所示:
解压hadoop
root用户登录shell:
配置hadoop环境变量
|
|
修改/usr/local/hadoop的属主和属组为hadoop:
配置本地模式并测试
Hadoop 默认模式为非分布式模式,无需进行其他配置即可运行。非分布式即单 Java 进程,方便进行调试。不使用集群文件系统的,只是个调试查看模式,不会启动什么DataNode这类的进程。
可以执行例子来感受下 Hadoop 的运行。Hadoop 附带了丰富的例子(运行 ./bin/hadoop jar ./share/hadoop/mapreduce/hadoop-mapreduce-examples-2.6.0.jar 可以看到所有例子),包括 wordcount、terasort、join、grep 等。
在此选择运行 grep 例子,我们将 input 文件夹中的所有文件作为输入,筛选当中符合正则表达式 dfs[a-z.]+ 的单词并统计出现的次数,最后输出结果到 output 文件夹中。
hadoop用户登录shell:
执行成功后如下所示,输出了作业的相关信息,输出的结果是符合正则的单词 dfsadmin 出现了1次:
注意:Hadoop 默认不会覆盖结果文件,因此再次运行上面实例会提示出错,需要先将 ./output 删除。
安装部署伪分布式Hadoop
Hadoop 可以在单节点上以伪分布式的方式运行,Hadoop 进程以分离的 Java 进程来运行,节点既作为 NameNode 也作为 DataNode,同时,读取的是 HDFS 中的文件。
Hadoop配置文件说明
Hadoop 的配置文件位于 /usr/local/hadoop/etc/hadoop/ 中,伪分布式需要修改2个配置文件 core-site.xml 和 hdfs-site.xml 。Hadoop的配置文件是 xml 格式,每个配置以声明 property 的 name 和 value 的方式来实现。
Hadoop 的运行方式是由配置文件决定的(运行 Hadoop 时会读取配置文件),因此如果需要从伪分布式模式切换回非分布式模式,需要删除 core-site.xml 中的配置项。
此外,伪分布式虽然只需要配置 fs.defaultFS 和 dfs.replication 就可以运行(官方教程如此),不过若没有配置 hadoop.tmp.dir 参数,则默认使用的临时目录为 /tmp/hadoo-hadoop,而这个目录在重启时有可能被系统清理掉,导致必须重新执行 format 才行。所以我们进行了设置,同时也指定 dfs.namenode.name.dir 和 dfs.datanode.data.dir,否则在接下来的步骤中可能会出错。
修改配置文件 core-site.xml,配置Hadoop的核心属性
|
|
修改配置文件 hdfs-site.xml,定义hdfs的属性
|
|
注意:如果需要其它用户对hdfs有写入权限,还需要在hdfs-site.xml添加一项属性定义。
HDFS进程有许多属性可以定义其工作路径,如dfs.namenode.name.dir属性定义的HDFS元数据持久存储路径,默认为${hadoop.tmp.dir}/dfs/name。
dfs.datanode.data.dir属性定义DataNode用于存储数据块的目录路径,默认为${hadoop.tmp.dir}/dfs/data。
fs.checkpoint.dir属性定义的SecondaryNameNode用于存储检查点文件的目录,默认为${hadoop.tmp.dir}/dfs/namesecondary。
为了数据可用性及冗余的目的,HDFS会在多个节点上保存同一个数据块的多个副本,其默认为3个。而只有一个节点的伪分布式环境中其仅用保存一个副本,这可以通过dfs.replication属性进行定义。
执行 NameNode 的格式化
|
|
成功的话,会看到 “successfully formatted” 和 “Exitting with status 0” 的提示,若为 “Exitting with status 1” 则是出错。
开启 NameNode 和 DataNode 守护进程
|
|
解决:
再次启动:
启动完成后,可以通过命令 jps 来判断是否成功启动,若成功启动则会列出如下进程: “NameNode”、”DataNode” 和 “SecondaryNameNode”(如果 SecondaryNameNode 没有启动,请运行 sbin/stop-dfs.sh 关闭进程,然后再次尝试启动尝试)。如果没有 NameNode 或 DataNode ,那就是配置不成功,请仔细检查之前步骤,或通过查看启动日志排查原因。The hadoop daemon log output is written to the $HADOOP_LOG_DIR directory (defaults to $HADOOP_HOME/logs)。
查看NameNode 信息
成功启动后,可以访问 Web 界面 http://172.16.7.153:50070 查看 NameNode 和 Datanode 信息,还可以在线查看 HDFS 中的文件。
测试hadoop
上面本地模式的例子,grep读取的是本地文件系统上的数据,本地模式是不使用集群文件系统HDFS的。
伪分布式读取的则是 HDFS 上的数据。要使用 HDFS,首先需要在 HDFS 中创建用户目录。
1.在HDFS中创建目录
2.接着将 ./etc/hadoop 中的 xml 文件作为输入文件复制到分布式文件系统中,即将 /usr/local/hadoop/etc/hadoop 复制到分布式文件系统中的 /user/root/input 中。我们使用的是hadoop用户,并且已创建相应的用户目录 /user/hadoop ,因此在命令中就可以使用相对路径如 input,其对应的绝对路径就是 /user/hadoop/input:
3.复制完成后,可以通过如下命令查看文件列表:
4.伪分布式运行 MapReduce 作业的方式跟单机模式相同,区别在于伪分布式读取的是HDFS中的文件(可以将单机步骤中创建的本地 input 文件夹,输出结果 output 文件夹都删掉来验证这一点)。
5.查看运行结果的命令(查看的是位于 HDFS 中的输出结果):
结果如下,注意到刚才我们已经更改了配置文件,所以运行结果不同。
6.我们也可以将运行结果取回到本地
7.Hadoop 运行程序时,输出目录不能存在,否则会提示错误 “org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory hdfs://localhost:9000/user/hadoop/output already exists” ,因此若要再次执行,需要执行如下命令删除 output 文件夹:
注意:运行 Hadoop 程序时,为了防止覆盖结果,程序指定的输出目录(如 output)不能存在,否则会提示错误,因此运行前需要先删除输出目录。在实际开发应用程序时,可考虑在程序中加上如下代码,能在每次运行时自动删除输出目录,避免繁琐的命令行操作:
8.若要关闭 Hadoop,则运行
注意:下次启动 hadoop 时,无需进行 NameNode 的初始化,只需要运行 sbin/start-dfs.sh 就可以了。
启动YARN
注意:伪分布式不启动 YARN 也可以,一般不会影响程序执行。
玩过Hadoop V1版本的可能会疑惑,启动 Hadoop 后,见不到所说的 JobTracker 和 TaskTracker进程,这是因为新版的 Hadoop 使用了新的 MapReduce 框架(MapReduce V2,也称为 YARN,Yet Another Resource Negotiator)。
YARN 是从 MapReduce 中分离出来的,负责资源管理与任务调度。YARN 运行于 MapReduce 之上,提供了高可用性、高扩展性。
上述通过 sbin/start-dfs.sh 启动 Hadoop,仅仅是启动了 MapReduce 环境,我们可以启动 YARN ,让 YARN 来负责资源管理与任务调度。
1.首先修改配置文件 mapred-site.xml
2.修改配置文件 yarn-site.xml
3.启动 YARN (需要先执行过 ./sbin/start-dfs.sh)
启动 YARN 之后,运行实例的方法还是一样的,仅仅是资源管理方式、任务调度不同。观察日志信息可以发现,不启用 YARN 时,是 “mapred.LocalJobRunner” 在跑任务,启用 YARN 之后,是 “mapred.YARNRunner” 在跑任务。启动 YARN 有个好处是可以通过 Web 界面查看任务的运行情况:http://localhost:8088/cluster,如下图所示。
在执行下上面的任务:
但 YARN 主要是为集群提供更好的资源管理与任务调度,然而这在单机上体现不出价值,反而会使程序跑得稍慢些。因此在单机上是否开启 YARN 就看实际情况了。
4.关闭 YARN 的脚本如下
注意:不启动 YARN 需重命名 mapred-site.xml。如果不想启动 YARN,务必把配置文件 mapred-site.xml 重命名,改成 mapred-site.xml.template,需要用时改回来就行。否则在该配置文件存在,而未开启 YARN 的情况下,运行程序会提示 “Retrying connect to server: 0.0.0.0/0.0.0.0:8032” 的错误,这也是为何该配置文件初始文件名为 mapred-site.xml.template。